Currently, a large number of devices communicate with each other using IP. To provide mobility support to a mobile device, IETF (Internet Engineering Task Force) defines mobility support in IPv6 in the following Non-patent Document 1.
In Non-patent Document 1, mobility support is realized by introducing a home agent (HA) into a home network. A mobile node registers a care-of address (CoA) acquired in a foreign link, with the home agent using a BU (binding update) message. The BU enables the home agent to create a binding between the care-of address and a home address (HoA) which is a long-term address acquired in a home link.
The home agent has a function of receiving (intercepting) a message destined for the home address of the mobile node, and forwarding the packet to the care-of address of the mobile node by use of packet encapsulation (setting a packet as a payload of a new packet, also known as packet tunneling).
One problem with MIPv6 (Mobile IPv6) is that, in order to change a network connection point or in the case where a lifetime of a binding expires, a MN needs to send an update to at least one HA and CN (Correspondent Node). This puts a high load of signaling to a radio access network, especially on a fast moving MN. Besides, in the case where the MN uses RO (Route Optimization) with the CN, RR (Return Routability) and BU message transmission need to be performed at the time of network connection change, which causes an increase in average handoff time at the time of network connection change.
Thus, a significant time is spent in a handoff process in a session relating to a flow or a connection, as a result of which an increased end-to-end delay, jitter, or packet loss of media packets could occur. Such an end-to-end delay, jitter, and packet loss are undesirable for an application of high immediacy such as VoIP (Voice over IP), multimedia streaming, and video streaming. Moreover, a packet loss is undesirable for a flow of transmitting important text/data information. In a data application that establishes a session according to TCP (Transmission Control Protocol), too, a packet loss causes a decrease in TCP throughput or bandwidth efficiency in a radio access network in particular.
To solve such problems with MIPv6, a network-based local mobility management (NetLMM) protocol is currently receiving attention. In the network-based local mobility management protocol, the problems concerning MN signaling are completely resolved at least in a local domain. In addition, by enabling the MN to reliably identify the same prefix by such a network-based mechanism, the delay due to the handoff process can be reduced. In the network-based mechanism, there is no need for the MN to perform an address update in the CN, and reachability of the MN is maintained by network-based signaling executed in a local mobility anchor (LMA).
The NetLMM (Network-based Local Mobility Management) Working Group of IETF develops a protocol for providing mobility management for the MN using a network-based method in which mobility management is carried out in a manner transparent to the MN. Network-based local mobility management means that mobility of a node in a topologically localized network segment is managed not by the mobile node itself but by a network entity. To achieve network-based mobility management transparent to the MN, the MN is required to be able to identify the same prefix in the local domain. This prefix needs to be obtained from a router at a higher position in a routing hierarchy (desirably on a default routing path of every MN in the local domain) so as to benefit from local mobility management. The router which serves as a root of the prefix needs to have information about reachability to the prefix (prefix-based route), and eventually this prefix-based route needs to be created by the network entity.
A network-based local mobility management protocol standardized by the NetLMM Working Group is PMIPv6 (Proxy Mobile IPv6) disclosed in the following Non-patent Document 2. PMIPv6 is mainly designed to provide a normal IPv6 host (without a CMIPv6 (Client Mobile IPv6) stack) with a mobility management service in a local part of a network. CMIPv6 is realized by MIPv6 (Mobile IPv6) disclosed in Non-patent Document 1 and DSMIPv6 (Dual Stack Mobile IPv6) disclosed in Non-patent Document 6 which is an extension of MIPv6 to support IPv4. For example, in the case where the MN exists in a foreign PMIPv6 domain and identifies the same prefix in the local domain via an interface, there is no need for the MN to perform global binding registration with one or more home agents or one or more CNs. This is also effective for a node having a CMIPv6 stack. Moreover, in the case where the MN having a mobility management capability moves to the home domain, the MN can continue to identify the home network prefix/home prefix, with there being no need to execute location registration.
According to PMIPv6, a LMA (Local Mobility Anchor) has two functions. That is, the LMA supports both PMIPv6 operations and MIPv6 operations. Since the LMA has a functional capability of a HA, the LMA is hereafter also referred to as a LMA/HA. In PMIPv6, in the case where the MN connects to a PMIPv6 domain, the MN provides a network access identifier (NAI) during connection, to a MAG (Mobile Access Gateway). The MAG is a router for performing proxy local registration with the LMA on behalf of a directly connected MN or a MN under management. The NAI is passed to an AAA (Authentication, Authorization and Accounting) server for authentication.
When the AAA server authenticates the network connection of the MN, the AAA server sends a response to report an authentication success, to the MAG. The AAA server also provides a LMA address and a specific MN profile (e.g. an address configuration mode, a special policy to be applied to the MN while moving in the local domain), to the MAG. Having acquired these MN parameters, the MAG sends a PBU (Proxy BU) to the LMA. The MAG acquires a unique prefix associated with a connected MN interface from a PBA (Proxy BA), and then serves as a home link or a local home link (in the case of a visited domain). The PBU (or local registration) executed by the MAG is the same as the BU in MIPv6 except for a “P” flag indicating that this is a proxy BU.
As a result of executing the PBU, reachability regarding the MN is generated in the LMA. Basically, the LMA has a reachability state for a unique prefix (a prefix unique to each MN) of the MN acquired in the PMIPv6 domain. A reachable address associated with this unique prefix is an address of the MAG. The MN configures an address using the unique prefix received in the PMIPv6 is domain, in a stateful or stateless address configuration mode. Since each MN acquires a unique prefix, a prefix-based cache in the LMA makes the MN reachable.
Every data packet reaching the LMA is tunneled to the MAG connected to the MN. Conversely, every data packet reaching the MAG from the MN is tunneled to the LMA. A neighbor cache table in the MAG includes a binding between a PMIPv6 local address of the MN and a link layer address used to transmit a packet to the MN. The PMIPv6 local address is an address obtained from the unique prefix provided to the MN in the local domain.
PMIPv6 disclosed in Non-patent Document 2 provides multihoming support, in addition to a transparent proxy mobility service. Here, a MN having a plurality of interfaces (multi-interface MN) is connectable to the PMIPv6 domain via all interfaces. The MN is capable of moving in the domain without executing mobility-related signaling, with there being no need for a change in a layer 3 protocol in a protocol stack. Multihoming is basically supported by the LMA assigning a unique prefix to each interface of the MN and maintaining a PMIPv6 binding related to each interface of the MN as an independent mobility session. In a PMIPv6 multihoming protocol, in addition to assigning a unique prefix to each interface at the time of initial connection, there is a need to maintain the assigned prefixes and sessions established using these prefixes without adversely affecting session quality (QoS: Quality of Service) when the MN having the plurality of interfaces moves in the local domain, to thereby provide completely transparent mobility management.
The multihoming support is also discussed in the MEXT (Mobility Extensions) Working Group of IETF. This Working Group is intended to enable a mobile node to configure different care-of addresses using one or more interfaces, and also enable the mobile node to receive a packet destined for a single long-term address (home address) via all interfaces or care-of addresses. This method is described in detail in the following Non-patent Document 3.
The technology disclosed in Non-patent Document 3 is discussed with regard to 3GPP (3rd Generation Partnership Project), but is also applicable to other public networks (e.g. 3GPP2, WiMAX Forum, Broadband Forum).
3GPP seeks application to a global heterogeneous architecture including various types of radio access networks (i.e. all networks connectable to an EPC (Evolved Packet Core network)), such as a wireless local area network (WLAN), a cellular network, a third generation network (3G network), and a wireless WAN (wide area network).
The global heterogeneous architecture is typically called a PLMN (Public Land Mobile Network), and is effective in realizing seamless mobility during vertical handoff or during simultaneous access through different access technologies. The global heterogeneous architecture is also effective in supporting different types of application services having very high QoS (e.g. real time video, VoIP, information-critical data, and so on).
Non-patent Document 3 discloses, with regard to connection by a MN via a 3G access network, that PMIPv6 is not only a GPRS (General Packet Radio System) tunneling protocol (GTP) but also a primary mobility management protocol for managing mobility. The use of MIPv6 through 3G access is restricted, and MIPv6 is used only for sending a de-registration BU when returning to a home or when executing a dynamic bootstrapping function to attain secure association with a HA. The MN can use MIPv6, PMIPv6, or MIPv4 through other access such as WiMAX access or WLAN access. For example, a mobility management mechanism when the MN connects to a 3GPP core network through WiMAX may be any of MIPv4, MIPv6, and PMIPv6, and a mobility management mechanism when the MN connects to the 3GPP core network through WLAN access may be any of MIPv6 and PMIPv6. Even when such a wide range of technologies are available as a mobility management mechanism, the system is restricted to the use of a specific mobility management mechanism through a current access technology type.
It will become necessary in the future that a MN having a plurality of interfaces of different types moves in a 3GPP network and performs simultaneous connection via different types of interfaces to attain multihoming advantages (e.g. load sharing, load balancing, fault tolerance, reachability, preference setting). Here, mobility of the interfaces may be managed by different mobility management protocols.
Since there are two main mobility management protocols, namely, MIPv6 (i.e. CMIPv6) and PMIPv6, in 3GPP these protocols will be developed in a mixed manner in the future. As an example, a MN having a plurality of interfaces manages all interfaces in one access domain, while a network using the PMIPv6 mechanism completely handles mobility of the MN having the plurality of interfaces in another access domain. Moreover, in a variable manner in some access regions, mobility of an interface of a CN having a plurality of interfaces is managed by the network, while mobility of another interface of the CN is managed by the MN itself. Such different management is performed using, for instance, a preference of the MN based on route optimization and/or a preference of the network based on load balancing.
In 3GPP disclosed in Non-patent Document 3, a mobility management mechanism relating to network connection of a MN through a specific access technology may be determined by static configuration or dynamic configuration. In the static configuration, for example, a mobility management mode relating to a specific interface of a mobile node may be pre-configured, where the MN obtains this information beforehand or the network reports this information upon connection so as to prevent a change of the determined mobility mode type. A specific mobility mode via an interface is determined based on an access technology type and a roaming agreement. Meanwhile, in the case of using the dynamic configuration mode, it is possible for the MN or user equipment (UE) to negotiate for a suitable mobility mode used via an interface connected to a specific access network. Note that the terms UE and MN are interchangeable and both denote a mobile terminal in this description.